• Replace null-forgiving operator with null-coalescing throw in exception factories
• Use null-conditional operator in MultiAppend catch block for safe status access
• Prevent NullReferenceException on transport-level gRPC errors
• Surface original RpcException instead of masking with NRE

Replace null-forgiving with null-coalescing throw

• Replace GetRpcStatus()! with GetRpcStatus() ?? throw ex in FromRpcException factory method
• Ensures original RpcException is thrown when status is null

src/KurrentDB.Client/Core/Exceptions/AccessDeniedException.cs

Replace null-forgiving with null-coalescing throw

• Replace GetRpcStatus()! with GetRpcStatus() ?? throw ex in FromRpcException factory method
• Prevents NRE by throwing original exception when status is unavailable

src/KurrentDB.Client/Core/Exceptions/AppendTransactionMaxSizeExceededException.cs

Replace null-forgiving with null-coalescing throw

• Replace GetRpcStatus()! with GetRpcStatus() ?? throw ex in FromRpcException factory method
• Handles null status gracefully by rethrowing original exception

src/KurrentDB.Client/Core/Exceptions/NotLeaderException.cs

Description

MultiStreamAppendAsync rethrows the caught RpcException via throw <switchExpr> (default arm
returns ex), which resets the exception stack trace to this catch block instead of preserving the
original throw site. This makes transport-level failures harder to debug even though the original
RpcException type/message is preserved.

Code

src/KurrentDB.Client/Streams/KurrentDBClient.MultiAppend.cs[R82-85]

+				throw ex.GetRpcStatus()?.GetDetail<ErrorInfo>() switch {
					{ Reason: "STREAM_REVISION_CONFLICT" }         => WrongExpectedVersionException.FromRpcException(ex),
					{ Reason: "STREAM_TOMBSTONED" }                => StreamTombstonedException.FromRpcException(ex),
					{ Reason: "APPEND_RECORD_SIZE_EXCEEDED" }      => AppendRecordSizeExceededException.FromRpcException(ex),

Evidence

The catch block throws the result of a switch expression whose default arm evaluates to the caught
ex; throwing an exception variable/expression (as opposed to throw;) resets the stack trace to
the current throw location, obscuring the original gRPC failure site.

src/KurrentDB.Client/Streams/KurrentDBClient.MultiAppend.cs[81-89]
Best Practice: Microsoft Docs (.NET)

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`MultiStreamAppendAsync` currently rethrows the caught `RpcException` using `throw <expression>` where the expression may evaluate to `ex`. This resets the stack trace to the catch block, reducing debuggability for transport-level gRPC failures.

## Issue Context
This PR’s goal is to avoid masking transport failures (null `GetRpcStatus()`) and surface the original `RpcException`. Preserving the original stack trace aligns with that goal.

## Fix Focus Areas
- src/KurrentDB.Client/Streams/KurrentDBClient.MultiAppend.cs[81-89]

## Suggested approach
Rewrite the catch block to use statement-form control flow so the fallback path uses `throw;` (or `ExceptionDispatchInfo.Capture(ex).Throw()`) instead of `throw ex`:

- Compute `errorInfo = ex.GetRpcStatus()?.GetDetail<ErrorInfo>()`
- If `errorInfo?.Reason` matches a known reason, throw the typed exception
- Otherwise, `throw;` to rethrow the original exception with its stack trace preserved

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools